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pastecere 
The Input-Output System 

8.1 Introducti‘n | a 

In many early aperauine system desieue “ne eopevec tees - the 
input output cont ol system (I0CS) sia ede a central conceptual and func- 
tional Pei. i the pre-multiprogramming, batch speratins systems, in 
fact, many supervisory functions had to ia en dunt output control -- 
e.8., control over queued jobs: control for management and operation of | 
secondary storage, control for operation of display devices and other 
peripheral equipment, etc. A system Seencumet (or subsyvecem déaiener) 
for such operating systems outa: needis veo his professional eapatence 
without acquiring a reasonable familiarity ath the buenas of the. 


‘[Iocs for his "installation". — 


By sgnpeaet the role played by the (upaevouepue Sparel syste in a 
long-lived Multics system is decidedly secondary, at least from a conceps 
Gat point of view and certainly tends to diminish over time. Even from 
a Peacoat Sint of view the: eetative importance in Multics enjoyed by 
the software having responsibility for I/O may tend bo -artenuare in time, 
In fact, it will probably prove true that many Se eoea most subsystem de- 
ieee may be able to aehieye their respective objectives wha lertematais 
entirely oblivious to the IOCS details of ul eioa. In the next few para- 


graphs of this introduction we shall enlarge on (justify) this viewpoint. 


One of our objectives in this chepter is to describe the degrees of 


involvement in or awareness of I/O system details that are appropriate for 


the déader: depending on his iMterese and on the type of subsystem ne may 
be ataaniae to design. Before we can succeed with this soqeetive it is 
believed that a esaeouaniy complete top-down view of the Multics I/0 

sy eben, oceanieacion is needed, This we attempt in Section 8-2. Those 
reading this chapter in its entirety will (hopefully) gain some insight 
on the relationship of the I/O system to ie renee supervisory finevieds 
of uuleies (eeneets iy the file system) that have been described in pre- 


ceding chapters. | 


There are two related views of Multics which suggest a secondary role for 

I/O in Multicss: First, there is the central fact that the file system sates 

known and dynamically links Files that wee stored as the hierarchy, ive., within @ 
the system, ‘to the arowasede that legitimately request this seueiee. It does 

soe matter whether these files reside on drums, disks or tapes. The users 

(or for that matter other supervisory modules) are unaware of any explicit 

data iovedenk in aecessiue these segments even though physical eeauetce 

from actual secondary devices to central memory may in fact be involved and 

some duly incurred, The pequiwed data or procedure object from the hierarchy 

is made part of the virtual meneLy of the "requesting" process in a manner 

such that any data euencar that is involved in ee transparent at the 

Vevel of ordinary source coding. In other systems, particularly in most 

earlier ones, a request for an information object on secondary storage always 
required an explicit request fox an I/O transfer in the "source/sink" sense. 

That is, the source of the object desired had to be identified as : named 

object and/or location. Correspondingly, if information was to be removed @ 


from main memory , it was necessary that the destination (sink) be identified 
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-as a named object and/or location, and the transfer (often along with 
parameters to afford control for a particular type of transfer) be expli- 


citly initiated. 


The Second view stems fee the Face that the iarowiaeion Seorees within 
the Multics file system te esen ended, being basically a growing storage. 
Hence, over time there will be a pendency for an inevsaa ine proportion of 
the ieee ied needed by a ee to be made known (added to virtual memory) 
fiyonen the service of the file system. The porelva observation is the 
diminishing frequency or need for data and programs that are "original", 
i.e., that originate supeiae: tie system auniae execution of the process 
and hence must be input via an I/O activity. In the limit, the Multics 
I/O activity stil be related only to the one or more 1/0 devices that a 
| user's process would have direct BG di ute. morn eee conversation 
with the system. In most Saes6 this is simply his bysewEtter or TV console. 
Moreover, in such cases, thought fully designed system Bacau euenen one 
are supp lied; offering the Sree eameE the option to ona oblivious to 
specific neo piee: of the 1/0 system, and to the fact that his process is 


actually making use of this facility. 


The reader should not Supstee deichiy 46 the conclusion, however, 
that the Multics designers’ ust apieceiuatias been to erect a barrier 
that prevents the (system ot user) Specie from acquiring and ge Statns 
full Goutre) over I/0 devices, matesee they gage be they tapes, special 
display devices: special Senmunieseioes channels, etc. On the contrary, 
user processes are able to "negotiate" with the system administrator, who 
controls distribution of I/0 cients. sc acquire particular 1/0 deyices 


(and/or channels). Then, with user code, the user process may program the 
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control of these I/0 devices (and channels) and operate them with the full © 
freedom that is normally accorded a hardcore system programmer. One of | 

our purposes in this chapter is to provide at least an initial guide to 


this programming flexibility for those interested. 


In brief, the Multics 1/0 avaiteii has been designed using side vines 

that would be followed in the design of any good multi-purpose tool: 

a) the simplest, most commonplace use of it requires only a minimum 
of knowledge and skill -- and the juetheaa for such simple oumen. 
mode) use is also minimized, 

b) to aot race more tailored (special purpose) services Petes is added 
cost -- both in the time that must be committed es understand 
how the tool works and in the actual overhead that will be faces. 


red in execution, | | : © 


8.2 1/0 System Organizational Overview 

In our introduction we claimed that there are different re or 
degrees of potential involvement in 1/0 system implementation that would 
be appropriate to each subsystem ape licettén. We shall enumerate and ex- 
emplify these iia succeeding sections. But, first, we are in need of an 
effective frame of reference to suewanted meaning for the delineations we 
snail be making. An organizational sveruien of the I/O system is what is 


wanted for this purpose. 


Such an overview must begin by recognizing an overriding design 
objective for any general I/O system; namely: the input/output operations | 


stated in the programs or service procedures that a user writes should 
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specify only those device functions that are required for the application 


| at hand, leaving to the system the responsibility for gauging the degree 


of device independence implied by the user's request. In this way a user 
who avoids such ee er re ee is free to designate substitute devices 
as may be dpecopetare: while adhering to eh device dependencies that are 
jawed by the stated I/0 function requests. “(For most ordinary users whose 
sole I/O device is normaly just the console, this Spiced ise amounts EG: 

an aoporcunity for the user to Stace his I/O requests in a mannose anne 
peiiiee: davide. dnaependanee< Moreover, ee aden or special idiosyn- 
crasies of the particular I/O device used in this fashion is of no concern 
to him either.) For this reason user-coded 1/0 operations of a process 


should ordinarily be independent (or as independent as feasible) of the 


| particular device and model, or even of the type of device, e.g., typewriter, 


as opposed to teletype or tape. © 


There are two clear reasons for this crucially important epjactive. 
First, we must presume that at any given time a system will generally 
seconbagee several types of I/O devices and models. Each is likely = 
require different programmed control, Each may have dieecient character 


sets, and may be intrinsically different in various respects (e.g., line 


printers are not backspaceable, tapes are; some tapes can be read backwards 


as well as forwards, while card readers are never designed to read cards 
backwards, etc.) Second, we presume that I/O devices become obsolete and, 
over time, are replaced by new models of the same or different types, 


C52. keyboard-TV versus typewriter. Clearly, if programs are to be re- 


usable, if processeg are to be repeated with minor or no variation in the 


nature or effect of their I/O operations during reuse of these programs, 
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then recognition of device independence must be a planned part of the 


programming system for I/O operations. 


pie Ban conen to anise for the needed device independence is to re- 
gard the I/O resource needed to complete se given I/O operation not as a 
real or physical resource, as for instance a particular card reader, but 
as a virtual (pseudo) 1/0 resource that is descui bed in terms of the func- 
tions it must be capable of performing, which is mapped by the system to 

; particular real resource at run time, using whatever I/O Hay ice. ie 
available and convenient. The analogy here is with virtual memory, regard- 
ed as a resource, which is mapped by the aveten into particular blocks of 
core memory using the bavasntaetan and paging features of the hardware and 
in a way that is transparent es the user. Such an approach implies that 
all available input devices, rosapa lees of type (or location) are in some 
sunsexieecseabie equivalents and all output devices are correspondingly > 


equivalent. 


Unfortunately, agen. de we eveiuide the user's own console, which 
normally must be fixed during the life of the ota it is still a poor 
analogy if interpreted too strictly. The user must, when he so chooses, be 
able to decide what I/0 devices he wants ae (when there is a choice avail- 
able to him.) If, for instance, he wants to develop a subsystem whose out- 
put = optionally aig sathen G dedicated line Snes. 50-eo1umn card 
punch or 80-column card punch, he must be allowed to specify which one, or 


which combination of two or three, and in what prescribed order. In short, 
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a completely flexible I/0 re must provide Poe tebe designation.of 

én specifics of certain I/O operations -- and even of user- provided 
evade (or simulated devices) in certain cases. For example, a user 
develops a sii epneeis whose output will drive a ene acquired df eotay 
device. He may be penuiee: es eran the deta ted I/O coding for the 
control ee that qui (later referred to as a Device Interface Module 
or DIM). Those interested in seeing what is involved for stich an appli- 
cation will hopefully find this chapter helpful, but snoulaveesrd this | 


entire chapter mere ly a jump-off point for more extended reading of the 


MSPM) . 


Certainly some kind of compromise arrangement is needed eects Some 
users (most, in fact) may eae Hiei Bisteutes+s6 fase 1/0 is ee as 
sapiepinew revel sean cee while sehoea wae code T/O opexetionarbe partially 
or completely specifying the devices bares used and the programmed control 
to go with it. The former use the go-ealied paclace 1/0 calls, such as 
ios $read_ptr, while the latter will come to erips with and sepeetively: 
utilize the basic functions of the I/O system itself in varying feceses of 
involvement. Some details of ieee calls and related techniques are des- | 
: et ibed in sections 8.3 and 8.4. Readers may already have encountered 


descriptions of these calls in the MPM, 


The particular design approach taken in Multics is based on two prac- 
tical requirements, one having to do with the discharge of the system's 
responsibility for dispensing and recovery of all real 1/0 devices, and 


the other having to do with the run-time mapping of valid user-coded 1/0 - 
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‘operations, regardless of their degree of specificity, onto specific 
devices and in the manner and with controls appropriate to crave specific 
devices. 

First, it is recognized that at. eae gives time, as a consequence of 
the I/0 device needs of a process, certain specific I/0 devices (or device 
capabilities) must be allocated to each or any given (user) sreceea: The 
system's decision to allocate from available I/O device resources to a 
aeeceee aaa be made for any of several reasons. For ordinary situations 
the system is ania eeects to infer chase needs, e.g., the console is needed 
on which a user logs in. In more exotic sanee. the user can negotiate 
these allocations in advance with the system's administrator, or eventually 


obtain these resources at run-time via commands or library subroutine calls. 


Second, any prebndenee I/O operation siawia at source level, at least, 
be expressed (coded) in a general way that specifies the I/O source or 
sink, not by its device designation but only by a placeholder name for that 
Boueoe sink. (Moreover, as an added sonvedteace to users, it may be 
possible concede certain standard I/O operations so that even this name 


may be inferred from context.) 


For example, [and here we illustrate only schematically], rather 
than use a specific device designation, even though that device may in fact 
already be allocated to a process at the time its use is wanted, such as 


in the following forms: 


read from "card reader 2" into area 23; 


or input ("card reader 2", area_23 )  ; 
or read ("device 352", area 23) : (1) 
or input ("console 204", area 23) 3 
or call io (input,"console 204", area 23); 


we might instead say: 


‘read from the stream named "Billy" into area 23; 


or ~ read ("Billy", area 23); @ 
or call read ("my console", area 23); 
or call io (read, "my console”, area 23); 


depending on the syntax of the coding language being used. 


Here in examples (2), "Billy" and "my_console" are simply identifiers 
for sources of data. For such a eas statement to have any iganinerl 
effect, the eet ete device represented by that identifier fast be bound 

to or "attached" to (i.e., associated in some ayiths "Billy" or “my 
console" at some time after the device is wiiecated <6 the process and 
before the read statement is executed. The Multics I/O system is responsi- 
ble for maintenance a Supervision of these device-source name associations. 
Like-wise for output, names for sinks are used in write statements rather 

. than actual output device designations. Thus by analogy to the read 
examples in @) above we could conceivably picture something ie 

| write ("his console", "format 12", area 22); (3) 

in which "his console" is here intended to suggest the name of some sink 
(output device). The attachment ae ne given time may be to one of a set 


of several (different) devices. Thus, if a single process had several 
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consoles allocated, the process could simulate a "party-line" conversation © 
on the several consoles where the name "his console" could be attached 
and reattached, possibly cyclically, among the several different allocated 


devices. 


A generic name for elements of the set {source, sink } that has aus 
found favor is stream. We shall use this term frequent ly hereafter. Thus 
the term eer ean name!" refers to either a name of a source or a name of a, 
sink. It is clear why the word stream is selected since an input or output 
operation mieeesuc a stream of information (words, or characters, or bytes, 
or bits) flowing from a source (input device) or to a sink (output device). 
“Conceptually, the dt taching of a seecau name to a particular device is a. 
form of parameter binding. The device designation plays the role of the 
actual argument and the stream nanecaat of the formal parameter. In order 
éé annie more than one Nareumene” eons Same ieaeanatert Multics weeuides 
for the Aeeeehaie Ge a davies (assienaticn from a stream name so that subse-. 


quently another device can be attached to the same stream name. 


To carry out a read or write operation (call) of the type suggested 
in (2) and G) above, the following steps can now be visualized. The ete 
module that receives and is responsible for "interpreting'' this call must 
first perform a table look-ds (in a per process, per-ring data base) to 
determine the device desten een (aa pe.t device, constraint rules, if 
fn fae use, etc.) that is currently associated with the named I/0 spuean 
parameter, [Because attachments ace maintained on a per-ring basis, a sub- 
system Shae erccuree in a special ring can have a jiaetnet set of stream name © 


"meanings", |] 
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“In principle, assuming the ee call pacaMetene are consistent with 
the data kept in this so-called actach table”, this same 1/0 Soubtot 
aioduits can then convert this request into an we action ~- i.e, . bg eye 
Pacem the degied 1/0 operat ions after generat ing the required channel 
commands ™ etc. Because the system must be capable of support ing an open- 

ended number of devices, device types, and controllers, considerably more 
modularity ie ated for. da. an actual fact, the t/o control modu le’ mere Ly 
transmits the now more “specific 1/0 Poqueet as a call to an appropriate 
"specialist" module (called a Device Interface Module or DIM). There a 

one Sich apcenanaee module £6e each type of device. This DIM in turn _ 
takes ehaeee of getting the 1/0 request accomplished as a ieeeeeed in 


Figure 8-1. 


To get a better betes Ge what the specialist mane $56 is, it is 
vortiuntte to degress momentarily to consider some of the special char- 
acteristics of the GE645 I/O controller nacdwate. The input/output 
controller Havduare of Multics is designed so bad 2ccn individual 1/0 
device may be (and in fact normally is) in effect connected to a 
saeaesec le channel. By 1/0 eHeaber ae mean (here) conceptually a 


separate I/O processor capable of accepting commands that carry out 


* TBM set a trend by calling the I/O channel instructions on its model 
709 computer commands to distinguish them from the instructions of 
the CPU. This distinction became a rather conventional notation 

that has remained popular for over ten years. In the GE645, however, 
these channel instructions are called "data contral words" or DCW's. 
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1/0 operations.” Hence: eneniue speak dpeuk allocating a device to a 
process (group) we ant ise take for granted that the system also 
more or less Somanenely allocates a shanner fou this device. The Coe 
of the naniea the identity of the detec connected to it, and the identity 
of the current owner process (group) can be regarded as system-maintained 
in Soi een isneiseo roan eeci Geiae-O) os seen data bases available to the 


modules of the I/O system. 


Communication with the channels, i.e., initiating their activity and 
supplying them with their needed commands, receiving and interpreting the 


status information that they return, etc., is achieved in the GE645 system 


7 by providing a peripheral processor called a GIOC (Generalized 1/0 Controller), 


This active hacdeare device acts as a high speed "broker" to manage (and 
multiplex) the communication between memory and the many I/O channels 
(which bos ncasaineaeactaaed in the GIOC). Each GIOC is logically organ- 
ized to provide half quciies: Cons aay) oe ree saEwite for up to 2000 
input devices, output devices, or devices that alternate as input and. 


output devices , or up to 1000 full duplex units such as typewriter 


or keyboard-TV consoles. 


We can now return to complete our view of the I/0 system's handling 


of read/write calls as suggested in Figure 8-1. Each device interface 


* Those who later have occasion to study the reference literature on. 
the GE645 I/O Controller hardware will find that the term channel 
is used in a more restricted and technical sense. There, several 
such channels, taken together, comprise what we speak of in this 
chapter as an I/O Channel. | 


: Such as the IBM 2741 typewriter console. 
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| Figure 8-1 First simplified view of 1/0 system organization 
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module (DIM) performs a number of fumettones The description that follows 
is ieenired by a recent description of Graham’. 

The DIM converts a device idesenadut request into a device dependent 
ones In doing this, it must compile a program for the hardware input/output 
controller GIOC (which it can in turn supply to the target channel). The 
compiled areata reflects the re ee oe of the particular device to 
which the stream is ee It (the program) may include line controls 
in ae case of remote terminals, select instructions in the case of tapes, 
and Storey. In addition the device ieeeeses module may need to convert 
the internal character code used by the system into an appropriate char- 
acter code for eadegiee:. Typewriter terminals for example, come in aa 
ieee varieties. Vireialiy every different variety has different 


character codes. 


The device interface module, after compiling a program for the GIOC, 
calls a saddle that serves as an pater see for che GIOC to start the 1/0 
setae this GIOC program. It is the DIM's Seah Guer hae Rs interact with 
the CIOC Interface Module (abbreviated as GIM) rere this I/O request has 
been completed. This may require several calls to the CIM depending on 
the format of the channel programs that the GIOC can provide to the 


channels for execution. 


* "File management and related topics", by Robert M, Graham, () 1969, 
p. 48. Course notes issued at the 1969 Engineering Summer Conference, 
University of Michigan on Computer and Program Organization. 
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© | The GIOC ereeerace Module (a ring-0O CPU saa is responsible par 
the overall management of the GIoc. Thus, the GIM is also responsible for 
eer | monitoring of the operation of the GIOC. This requires answering 
jcereanes (1.8, that its code acts as an intercept hand lex for), recog- 
nizing completion of tasks (and transmitting to its saaiieeatutus anes and. 


tion deposited by the GIOC). 


A cial wotat of explanation for Figure 8-1 regards nae indi- 
cated entry points to the I/O Control Program. The entry attach is always. 
employed (to Sscabiaeh the appropriate stream name-device association in 
the attach table) prior to utilizing the entry points read or write for 
the same streams. The ane cy polne detach is used to nullify a previous 


attach stream name-device pairing. — 


a CT Pine 0 eee e000 oe ee 


If we now add ne powerful, in fact crucial, generalization to the 
' 4)6.Byatem iecanteacton picture painted thus far, we can then see the 
actual ee design avenviee in its entirety. That generalization is the 
one which permits segments to be substituted for I/O devices in the 
pace etc with eee names (let us pause briefly to let the last sen- 
tence sink in.) What we mean by this remark is that —_ named segment of a 
user's speeece aay be saptoged as a source or sink for a read write 
function, as if it were (or in lieu of) an actual I/O device. 
| | 
There are a number of important applications that are now possible as 


& a result of this type of generalization. For instance during a console 
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debugging session, information jan be read out of storage on to the user's 
eonseie Foe yieual wevigiearion. ee verified, sheeeedites ae ioc cance 
but tiga oneness might be more appropriately outputted to or 
and thus saved as files. To achieve this ab ccrive, the programmer 
might follow these steps; 
Ls (For debugging) Call attach to associate the stream name, say, 
"user output" with his console, e.g., tty302. 
“1p (For production runs, after debugging) Call detach to nullify 
the previous call to attach. Call attach once again, this time 
to associate the same stream name "user _output" with, say, 


<results files, 


Other Bawticatione are those that make it possible to simulate I/O 
devices for interactive or conversational interplay, sending sel i.e., 
output to data bases shared with other users, converting console seacieas 
to run absentee by placing on one file the Sequence of commands which can 
be read as an input file and placing (writing) the series of resulting 
responses on another file: (The dialogue's results can be Jeanie later 


at leisure by asking for a printout of the output file.) 


This pscate ue generalization of the notion of input/output is 
achieved in a mechanically almost trivial manner in Multics. The trick 
is “apis to create another specialist DIM called the file system interface 
| DIM, as shown in Figure 8-2, which papier the 1/0 system organization 
overview. Again we follow closely Branents dosertseiss of this module's 


function. 
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The file system interface DIM functions like any other DIM. However 


it does not call the GIOC Interface Module. The file system interface DIM 


is used to make a segment look like an I/O device, In its (per process) 


TT Riera rad —n se See 


Static storage, the file system interface DIM maintains a table holding 
status information for each segment which is being referred to as a 
device. When an attach call is made to the I/O control program for attaching 


a stream to a segment (instead of to an actual device), the requested seg- 


ment is initiated as a known segment ce not already known). [See oer 


6 as a refresher for the details on mak ing a segment known.) The file 
System interface DIM maintains in the table of status intotaatien separate 
read/write indexes Sethe current positions in the segment where reading 
or writing (a eating wigee. Subsequent read or write calls are processed 


by the file system interface DIM and consist of copying the requested 


information into or out of the segment at the position of the appropriate 


read/write index. After the copy is made, the index or "current pointer" 


is updated to the new position. of the segment, 


We have just seen how the I/O system may behave as a "customer! 
of the file system which Supplies needed services. One might wonder if 
the reverse of these roles is ever true. That is, does the file system 
through its page control module, when teeing to transfer a page of informa- 
tion from/to core and disk or tape storage, ever find itself to be a eustonee 
of the 1/0 system? Emphasis on objectives of modularity might cause one 


to guess the affirmative. In actual fact, however, considerations of. 


efficiency have dictated that paging I/0 in Multics be treated with Special 


purpose 1/0 software that greatly streamlines the Proce sec 's task in 


initiating and controlling such 1/0. The details of this special purpose 
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Figure 8-2 Complete simplified view of the Multics 


I/O system organization 


AS another example, the Statement, 
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software should be of no interest to subsystem designers ani for this 


reason will not be covered here, 


8.3. Packaged I/O for Communication with the Console 
typacal of all operating systems ‘that support interactive processing, 


Multics furnishes several routines (and Baaptes them) to Seen the typical 


user's need fox an easy-to- express console I/O pedvae LG, one that requires 


a minimum of acquaintance with the I/O system SE eentZatien. These routines 


have been referred to as "packaged L/o'* jini da serve effectively as inter- 


faces with Ee 1/0 ae ey mapping the received call into the appropriate 


conde more technical) eae to the I/O system, 


One of the simplest of the interface routines currently available is 


the simplified print routine called ioa_ which can be used to construct 


and print messages made up of character strings, inpacees and pOnOres wetlicg. 


For instance, a call written in PL/1 Syntax, might be: 


aA 


call ioa_ ("date | “a “d, d, time nqen dq", 
"June", 20, 1969, 2014, 36); 


When executed this call would produce a typed line vies might appear as: 


date June 20, 1969, time 2014:36 


» pointer variable); 


call ioa_ (“overflow at “p 


* This is terminology used in the Multics Programmer's Manual, Section Ly. Beh 
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would produce when executed a typed line that might appear as 


euerEion at 274] 3263 


The first argument is a control string which is a Fort Of eoeaee codé 
Somewhat similar to a Fortran format (but more limited in purpose). We'll 
not dwell on the details of this. routine or its variants as they ane well 
described --- with additional illustrations --- in the MPM. We only consider 
here how functions like ioa_ Bes in the context of the operating system 


organization structure just overviewed in the preceding section. 


To understand how ioa_ is able to do its intended job we must appre- 
ciate the corns system service conventions that are obeyee for each 


process created at log-in. 


First, the identification of the console device-channel pair on 
which the log-in attempt is made is ageee by the user control ee Cie). 
the "answering service") that responds to the dialup. When log-in valida- 
tions are completed and the roe see is created on the user's behalf, the 
console device is allocated to that emeaeda process and the stream name 
"user_io" is "attached" to this device by calling the I/O control module 
at the entry point Seach and supplying as arguments the necessary informa- 
tion to complete a suitable entry in that process' attach table. (Note 
that the interface routine can be oblivious to the type of device the user 
is logging in on. The I/O control module has responsibility for pene, 


the 1/0 request to the appropriate device interface module). In Section 
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8.4 we shall Pear closer look at this bit of business, but for the 
moment we mere ly note that in fact several calls are made to the attach. 
ehtry,. velit ine in a capi entry that shows the names "user pueoue! Gas 
well as "user-input") as synonyms for the stream name , "user _io!', where 
“user io" tieans the tty he logged in wae Second, we must also appreciate 
that ioa_ i written to call the write function using "user output" as. 
the I/O name. In general, packaged I/O interface routines always use 

the fixed names "user output" or "user_input" as I/O names for their 


function calls to the I/O System. 


We now see that when the log-in process e completed, and the user 
is "put in charge", the necessary connections that essentially enable 
ioa_ co pee form properly have all been made. The same connections (i.e., 
attachments) are also made for wehee packaged I/O routines. Of particular 
interest in this category is a pair of Poutines Ede reading or writing’ 
typewriter I/O. These two routines, shoes full names are ios $read_ptr 
and ios $write_ptr, are fully described in the MPM. 

For example, 

| call ios $read ptr (stringy ptr, rdmax, rdcount) : 
requests that up to rdmax characters be accepted from the console for 
assignment to the ehecneeed seins ware pointed to by stringv ptr. 
The output argument rdcount reports the number of ahaeaceee: actually _ 


read from the typed line, 


A subsystem writer will be pleased to observe that the effective Sources 


or sinks for packaged I/O routines are easily changed to any device or file 
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of his choosing. For instance, if-the a explicitly called I/O routines © 
in the Subsystem are of the packaged variety, then to convert ehe- subs: 

‘system to ou absentee, the only requirement for the change is to cause 

Seaton of an I/O system call to detach the "user input" and/or "user_ 

output" synonyms from the stream name "user_io", and then cause explicit 

: seeack calls to reassociate the aie’ "user_input" and/or "user output" 

with the designated files (named segments). These i/0rey tea eei ts could 

be Lvssieeds Gaxceeear iy at command level) just after log-in or at any 

‘Cia afterward hea absentee mode execution becomes appropriate. This 


flexibility may motivate some readers to investigate the attach call and 


the related I/O'system calls that are discussed in the next section. 


8.4 1/0 System Calls (ios_) .* 4%. | | - ag? 
These direct calls to the 1/0 system, a total. of over twenty by . © 

current count, are enumerated and ene described in the MSPM as well as 

in the Multics Programmer's Manual. (The details for specie indcall the 

arguments for these calls, ieee are somewhat scattered throughout the 

latter.) . Here we shall give brief descriptions of some of these serie 

and their use but avoid a detailed technical description. Four of the 


| most frequent ly: used entry points are listed in Table 8-1. 


8.4.1 ios Sattach 


To attach a device to a stream name, the programmer must specify the 


following (indicated arguments* are given to the left): 


* The first three arguments (ionamel, type, and ioname2 must be @ 
supplied as character strings). | : : 


Table 8-1 


The Most Frequently Used 1/0 System Entry Points and Their Arguments 


Entry point name Arguments 


ios $attach 


ios S$detach 


ios Sread : 


ios Swrite 


* for details, see Section 1.41, Reference Data Section MPM 


+ for details, see Sections 1.4 and 1.41, Reference Data Section, MPM 


+ for details, see Section 1.4, Reference Data Section, MPM 


| Loname | ionamel typet ioname2* | modet | wkspace nelem} nelemt disposal | Status# 
| | COBEPEE? (output) 


€C-8 


ioname 1 


type 


ioname2 


mode 


status 
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pneeee ace name 

the type of device, to designate the sppEeoiate DIM, | 
e.g., ‘‘tdsm'' for the tape DIM, or eure the file 
system interface DIM, 

the device designation, e.g., "tty138" for a typewriter, 
or "Harry" for a file (i.e., a relative path name ) 

a code to designate the kind of restraints to be placed 
on the use of the degies. its method of accessing, and 


its interpretation of the data representation (and any — 


other type of constraint or optional use or function that 


is deemed appropriate during this particular attachment.) 


the name of a (/2-bit) variable to record the response 


of this request .. i.e., in which to receive the reflected 


error messages, warnings, or other advice from the modules 


that are the dynamic descendents of this call. 


~The MPM (Reference Data Sections 1.4, and 1.41) maintains an up-to- 


date list of all the DIMs that one can designate in an attach call. This | 


reference also provides the subsystem writer a complete list of function 


calls besides attach, detach, read and/or write that are meaningful for 


each system-supplied DIM. The same reference supplies a list of the de- 


fault modes that are set for use in package I/O read/write calls. The 


coding for modes recognized by the system-supplied DIM's is explained in. 


the same reference. (Subsystem writers who must write their own DIM's are 


urged to follow this coding although the particular code scheme that one 


devises is up to the DIM designer, since the I/O control module simply _ 


8-25 


transmits this code to the target DIM and is seherwine oblivious to it.) 
he mode code fbr se ostenesanpiadd DIM is siapigi Shapseeet string 

‘ee concatenated seecdeetaue code characters, one or move characters per 
each use, access or data mode, poe eecaies a mode gede to attach a 
tape unit for reading only (use), Poneaa only (access) and only logical, 
linear records (data) would be the concatenation, "RFGL" for readable, 


forward, logical, linear. 


In the initial Multics implementation the mode argument may be null 
Cie. ON") because the 1/O switch is not programmed to check the mode, 
Ultimately, howe ee. is planned that the "switch" will check heuge 
code portion of the mode argument (i.e., to see if codes R, for readable, _ 
and/or W ae seicapie are compatible with the attached device) and will 
pass the eenawnder of the mode argument ee aedée and data mode ee 


to the DIM for further compatibility checks. 


A complete explanation Garsteestacieas of the en ne called 
seubie de aieesnaintained in the same Re ference Data Section (1.4). Many 
of these error eee should fake more senee upon completing ees 
reading of this seeete: (8.4). Attempts to attach a device should al 
if there is an incompatibility of the stopiied Bed tneate either with what 
is already recorded in the attach table for the process, or with what is 


recorded in or known about the target DIM, 


An attempt to attach a named segment for use as an input file will 
result in an error status return from ios Sattach if the specified segment 


cannot be found. An attempt to attach a specified segment for use as an © 
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output file will result in one of two actions. If the segment cannot © 
be found, then one will be created and'used (without comment). If 
the segment is found, writing into it will be by appending to the end 


of it. 


In MPM parlance the 1/0 control module (which maintains the attach 
table) is referred to as the "T/0 switch" because aueine function calls 
Like ios $read or foe Surite, the job of this module is to route or switch | 
the ineontae call not only to the appropriate DIM, but sarees. teed the 


call to the appropriate entry within the target DIM. 


Each target DIM has an eqeny point transfer vector, one entry per 
each of the functions supported by that DIM. The transfer vector is 

| Scnswlkea shee the DIM is called by the 1/0 splech for routing the call 
to cidehip eae tae: Puaettonaientey point, xe, ose ie Baeheoace: 

_ rewind, etc. A eases function that is not supported aren the parti-. 

cular DIM (e.g., to read re will reflect an error code when and | 

if it is called. (Section 8.5 gives more details on the design of a DIM 
including naming conventions for DIMs and poe the calls hs DIMs may 


receive.) 


By special design, a user who wishes to provide synonyms for a given 
stream name may ee er a call to ios Sattach in which the | 
"arguments take on their special meaning when the argument called type is 
supplied with the aie "syn", Woe gua to assign the string "his io" 


as a synonym for an already-attached stream named "her io" one could write: @ 


—6B-26 


call ios $attach ("his_io", "syn! "her io", mode, status) ; 


8.4.2 ios $detach 

To detach or ula 8% a previous attachment, i.e., delete the entire 
attach-table entry previously recorded for a given stream name -- remember, 
there may be one and only one entry for eae. Steer name -- one calls 
ios $detach and names the streamname and, as a eeaundaney check, the 
(presumed) device associated with that stream. A status return argument 
provides a report of the resulting action. Incompatibility (or invalid- 
ity) of the out deen oe will result in an error message reflected from 


the 1/0 control module (1/0 switch). | 


The input argument called disposal may be null (i.e., "") for most 


applications. It is planted in this call for future use, to provide special 


instruction to the system or operator for the disposal of dedicated 1/0 
“devices such as tapes, and/or magnetic tape drives. (Both tapes and drives 


can be considered as independent resources to be disposed of.) . 


“when fully implemented, a null value for the disposal argument will 
mean: ake the default action ae close out the eee allow future 
asatenment ee. aati user (e.g., dismount cnet eancye “MieSrnawively: 

a value of "hold" for che -aiapéeal argument will mean: keep ‘the device 


active ("I will be back"). 


8.4.3 ios $read 
To execute a read the caller is obliged to name the input stream 


(source) and a pointer argument (workspace) that identifies the destination 
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in the process! virtual memory where the input data is to be transmitted. 
Additional qualifying input arguments are the offset and the number of 
elements, nelem, that are to be read. The offset i from the beginning 
of the eoriepade in which to begin eeeeiiie the input data. [Offset is 
measured in elements where the element size is usually set by a default 

- convention for each DIM. Typical element sizes might be 9 bits for 
character-oriented streams or 36 bits for word-oriented streams}. The 
number of elements specified is, of course, subject to the soerene upper- 


bound restraint imposed by the segment size of the workspace. 


There aor output arguments, nelemt and Spaniel The former provides 
a report on che actual number of elements read ties the workspace while 
status provides the norma | sawiee on success or degree of success of the 
read spornead! The report can reflect error eepores transmitted from a 
variety of aGureee: inc luding the GIM, ot in the case of the file ieGieee: 
from file system nedaiae: (It may even reflect an error message that 
alerts the user to trouble Busse auras the preceding eeaneat ton -- an 
jndteat ton of interest during certain een sacus reading modes described 


later.) 


8.4.4 ios $write 

oscars seen from Table 8-1, this call emp loy@ the same ee of 
 eueuedtee Their interpretation is Ghat wou ld be dered Reeagmaces 
with ios $read. The workspace pointer and offset identify the place from 
which writing-out is to becin, The anes of elements to be written out, 
nelem, and che wuabee actually written out, ati. eeeuide input instruc- 


tion and output reporting respectively. Status provides additional infor- 
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mation to complete the reporting responsibility. 


8.4.5 Other calls 

Several calls se dvaniapie ee needs the subsystem writer see 
flexibility or control of the use of 1/0 devices. For instance, 

ios $changemode 

allows one to alter the current node OE a given attachment, Several 

calls deal with control over the synchrony of the pets or write operations 
and/or of the workspaces employed in these operations, te dont burden 
the reader here with the actual names of these calls or their arguments. 
These. can be found in che MPM. We wari: foueliee, dicrdee here to discuss 


the subject of I/O synchronization control at a conceptual level. 


Read/write synchrony refers to the type of coupling one wants (loose 
[asynchronous] or rigid [synchronous } ) bétuden the actual initiation of 
the 1/0 transfer and the corresponding read finite call in the user's 
program. “Workspace synchrony efere to the type coupling one wants (loose 
or Wigiay patweencche point in time when the I/O workspace has been 
| filled /emptied and the point in time when the program ae eee execution 
"shevond the read/write call (nae would cause the workspace to fill/empty.) 
These two types of synchronization are mutually ecthowonel. SO a user may . 
aint to gaceiey nee icutae combinations for his subsystem application when 
other than the systemwide default selections are aaated: The next few para- 
| graphs elaborate on each pe 708 synchronization penteol and saateuk several | 


applications, | 
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Read (eyacheousus or asynchronous) 

Shall 'read- ahead" be permitted or not? That is the Pecerdion. By 
ae er (asynchronous) we mean permitting the system to anticipate wine 
7 program's read request by issuing an 1/0 order to read the attached device 
before our program actually executes the corresponding read call. Read- 
ahead is what is meant by reed asyachcony and is precisely what is 
wanted in the typical Seabee read operation. This allows the information 
that pie, see types ahead to be available in core when the program issues 


the read call. Hence, the system's default mode for typewriter input is 


asynchronous. 


A read synchronous operation implies, "Don't read a thing from the 
device until a call for it fas! BGen issued. This ia mode Rees 
a user to the program, thus in si faek eeueeerae the normal master/slave 
interactive relationship between them. Now the program is in control of 
the user pues than vice eee Read eedennenens night be useful in 
eee computer-assisted instruction applications ax in situations where, 
Say, no further requests may be Seewetea Eton an inquiry station chat is 


attached to a subsystem. 


Write (synchronous or asynchronous) 


Shall "write-behind" be permitted or not? This is the question here. 
If so, then return is possible from the write call before all output infor- 
aigeles designated in the write call has been transferred to the device. In 
most applications write asynchronous is acceptable and in fact, highly dee ire 


able for the sake of efficiency (so long as it is safe). Write asynchronous 
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is the system's default decision. There Seecnees. however, where eee 
eeq tecnous operations are required. The systen, foe example, idee this 
mode of out put during automatic logout of a user to be sure that all mes- 
supeswand other 1/0  vaneaet ions have been completed before sada eubeed 


quent action. 


“Workspace aeaeieousus or asynchronous) 

‘Shall permission to return from a read/write call be pernieeed before 
the workspace designated in that call ee been filled/emptied? That is the 
. question asked here. The system's default decision is workspace sydenecusue 
‘(i.e., no return of control from the DIM until the workspace has been as- 
certained to be filled for the djedienatea read (or emptied for the desig- 
neuer. Caiteiven ig some speedup of a read/write asynchronous action 
can be achieved by opting for woxrlispace ‘asynchtonoud but Hae Ge ae 
pantie because a succession of reads (or writes) could conceivably cause 
chaotic overlaps in the workspace areas; ca. unless there is a peeeied 
ee application where the user feels safe in doing so, workspace gepnchron: 


ous is not recommended, 


To summarize our foregoing discussion, the defaurts con che synchron- 
savior options gees. 

Le eandine is asynchronous 

2. sritiag is asynchronous 


3. workspace use is synchronous 
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Still eee calls a eeu ide: ee user an opportunity for such functions 
ag abandoning data piled up as read-ahead in the input workspace so as to 
reuse this space for new reads. A symmetrical call aborts any, as yet 
shveteal1y unwritten, data that may be piled up as write-behind in the | 
output workspace. These calls may be especially ieerdl for designers of 
subsystems dealing with typewriter-like consoles where the read-ahead or 
write-dehinds can become numerous in certain conversations. Often the 
need - reset the enone pointers in the read or write workspace becomes 
essential to avoid frustrating the console user, for instance by seenee tne 
previously typed but now undesirable input or by typing out now unwanted 


results, 


Still other calls allow the user to control (or determine) the size 
of input or output elements for next (or current) reads or writes. | These 
calls may be useful in certain applications where the device is the type- 


writer or a file. 


In qaaeien. ened are ios calls to allow the user to control (or 
determine) the set of read delimiters and/or break characters in input 
streams. Read delimiters are weed to condition read calls (e.g., the new 
fine character for typewriter read calls) so they halt their scan of the 


input buffer after a read delimiter is seen (and transmit all characters 


seen up to that point, i.e., up to and including the read delimiter, to the 


user). Break characters are used to control the action of an "interactive" 
channel so that it will trigger a hardware interrupt (when such a character 


arrives over the channel), so as to make all data read since recéiving 
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ae last break character available ga thie user, Break characters are 
useful to achieve a form of code conversion or sii@iae nous as “cannoni- 
calization" (see MPM, Section 2,5 oe an orientation and a full explana- 
eP6A): They are also used to achieve erase and kill effects. These, 
too, are a form of inmates editing that has been Pound: eeaential iene 
the typing of input streams. (Section 2.5 of the MPM elaborates). For 
typewriters, new line is not only get as the read delimiter but is also 


set as a break character. 


When segments are attached as pseudo input devices, say for absentee 

jobs, it would be nice if the file eyeeen interface DIM could respond 

to both = delimiters and £6 break eharseesrs in input messages SO as 

to fully eimace the action and effects of, ee ee nr input 
data. Although the file system interface DIM does accept delimiters (e.g., 
new-line), it does not, however, accept break characters, pecausaca¢ is 
not an queeeaetive channel. Another point to note is that, as a result of 
a design decision, the file system interface DIM Supports (@eumies) no 


code conversion during input from a segment. 


The default values of new-line for the read delimiter and 9 (bits) 
for element size make it especially easy to have segiisate substitute for 
typewriter savieke (that transmit ASCII character strings). But the user 
may choose any read delimiter and/or any iecaae size sess executing 
appropriate calls to ios $setdelim and ios $setsize for the streamname 


in question. 
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The fact that the file system iter pace DIM does not itself a daub 
code conversion during input from a segment is no serious restriction 
either. The user's program that invokes the action of the file system 
DIM is certainly free to perform ele neeaee conversion steps either 


before or after the simulated input operation. 


Finally, as if this portfolio of possible user-originated I/O control 
weueaor been the Multics designers have planned an open end to the 
list in the form of a special, catch-all call, - 

ios Sorder 
This call permits the sophisticated subsystem writer to transmit special 
requests to the target DIM of subsequent read/write calls, such as the 
setting of hardware device modes on typewriters or tape drives, e.g., 


red or blue ribbon, high or low tape density. 


8.5 Designing a DIM 

Geepa-aay wie non-privileged device interface modules” for a variety 
of purposes, usually to control a particular device or set of devices, but 
occasionally to serve as an intermediate interface with existing DIMs. 
To construct a DIM that controls an getual device the sbaveten designer 


must become thoroughly acquainted with the channel adapter that communicates 


with the device (or its controller). The channel adapter is connected to 


* The current implementation of Multics includes certain privileged 

| (ring-0) system DIM's designed to satisfy certain high-performance 
requirements (e.g., typewriter response). The design details of 
these system DIM's are not considered in this Guide. 
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the GIOC. Additionally the programmer must become acquainted with the 


GIOC hardware, and with the software module that manages this hardware 


and that interfaces with the DIM on its out-going end. He must also | 


be familiar with the system-supplied I/O switch which must call the DIM. 


The DIM is the only module i dhe enerA of bangs that knows about the 
1/0 device being controlted. On the user's side of she DIM the I/0 switch 
routes the user's call to the proper DIM, checks pee and transmits sonpaeibis 
sets of arguments, otherwise generating and returning sa vopitate error. 
messages generated as a result of the I/O action itedi¢. On the device 
re of the DIM the CIOC Interface Module (GIM) aeaneariee control informa- 
tion es the GIOC, Belebestaud 2eecks to iaeeerupte eeceived from the GIOC, 
and interprets and transmits status information to the DIM. The GIM also 
iesatee and controls the use of channel bu eters that must necessarily 
tie outetde the eons virtual memory space. The GIM is designed so it 
need not care or the user mate Wee of a daannel that fe ae GIOC ''manager", 
assigns to che: Hee Ge ouen the DIM). Of the three modules in the chain, 
seme the I/O switch, the DIM, and the GIM, it is the GIM alone that 


provides for the system's safety in carrying out these various functions. 


A user may also design a pseudo DIM which acts merely as an intermediate 


module between the I/O switch and one or more existing DIMs. To write a 


pseudo DIM one need know nothing about the GIM or the hardware it serves, — 


A "broadcaster" module would be an example of such a pseudo DIM. 


Its purpose might be to receive a single write call from the I/O switch 
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and convert it to two or more ios $write calls via the switch, this time 
to the actual DIM or DIMs that will in turn cause replication of the message 


on the devices in the "broadcast" set, 


Siiichat carte. this idea is aPecer displayed. For example, we may 
picture a call of the form: 
call ios Sattach ("A", "broadcast", "C", "D", "E", mode, status); 
where we assume that "C", "D'', and "E" are I/O stream names that are them- 


selves already attached (to their respective devices). 


The coding fox the broadcast pseudo-DIM would then be. such as to 
anticipate and peoceee a call of the form | 
} call ios _$write (MAN, workspace, setae: Sede 
so as to generate and execute the following three calls (and then return); 
call ios $write (ren, workspace, offset, etc.); 
call ios $write ("D", workspace, offset, etc.), 


call ios $write ("E", workspace, offset, etc.)3_ 


In the subsections which follow we recite in a more systematic fashion 


a "checklist" of things a DIM writer needs to know. 


8.5.1 Conformity with other DIMs 
There are some general rules of conformity that are worth reviewing 


when approaching the design of a DIM. These ideas are given here. 
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It goes without saying that a DIM or pseudo DIM designer must become 


acquainted with and try to adhere to all the ios conventions for 
communicating between the oe and the I/O system. ‘In this way the 
new DIM can be used interchangeably with other DIMs and thereby 
preserve the an abaeanice of device independence. Conventions which 
are enumerated in the BF sections of the MSPM have to do with: 

(a) interpretation of error codes, 

(b) attach modes, 

(c) treating default strategies re: element size, read delimiters, etc. 
In the same spirit of maximizing uniformity of application, calls to 
ios_ through the switch should be matched to the device's func tions 
ine meaningful way, if necessary, us ing the many special calls 
already a aaane other system- supplied DIMs, e.g., ios $changemode, 


ios $setsize, ios $seek, ios $tell, etc., and as a last resort, 


ios Sorder. 


Achieving this type of conformity can well have a high payoff during 
the debugging of a new subsystem that includes a new DIM. Remember 
that during early debugging of the subsystem the actual I/O device 
will probably not be ohereadis connected to the aye ren. S65, the 
device will have to be simulated by using existing equipment, using 
the existing system-supplied DIM. (Letting the device be represented 
by a file and using the existing file DIM is regarded as the best 
choice.) Cutover to the actual DIM and the actual device should there- 
fore present fewer problems if the new DIM presents a similar. inter- 


face as the one used in the preliminary testing. 
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3. AS a general rule of good design the DIM should Be setseeuweed to 
expect any reasonable ios_ call and do something sensible with it, 
i.e., not eee: aes For example, if a device has only one read 
delimiter, say the new line character, then a call transmitted via 
the I/O switch to set the delimiter to new line should be accepted, 


(and of course ignored), 


elemswen See eee 0 beens 0 eee? = eee 


When the call to ios $attach is received o the I/O switch it in turn 
calls the attach entry of the target DIM. The latter must be coded to 
return a device pointer which can be used as an argument during subsequent 


function calls transmitted through the switch. 


The I/O switch employs a speeds amine sonventien in designating die! 
appropriate entry point in the DIM target. The switch i coded to accept 
a call of the form: 

call ios $attach (ionamel, type, etc.); 
as signifying that there exists a transfer vector in the target DIM's 
linkage section whose elements point, via links, to the respective func- 
tional entry points in the target DIM. This transfer vector begins at 
typeStype. For examp le, suppose one were writing a special DIM for the 
pdp/ computer regarded as a peripheral device. If the DIM is piven the 
type name "pdp7", and if the call to Brrach were: 

call ios $attach (“input 7", "pdp7", elCisa.2)3 
then the I/0 switch assumes that the segment <pdp/> has an entry point 


located at <pdp7>|[pdp7] at which there is to be found a vector of transfer 
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instructions, one to each supported functional entry point in the DIM, 


Since the eee ia Gok cicse Gaeasclnt eawaret instructions appear 
“is fixed by still another system-wide pemienciGh for all DiMe*, ‘the 1/0 
suLter is able to weaeuee a call to the seated point (offset) in the DIM's 
transfer ee a6 as bs reach the desired functional entry point. Thus, 
if the sean: poetics for the read entry transfer is the third Siseece, 
in the vector, then a function call o# the form 

call ios $read ("input 7", workspace, offset, etc.); 
would find the 1/0 switch transferring into the third element a; the | 
Nevane oe vector of aio i.e., at <pdp/>| [pdp7) 42, Here it seats be 
expected to find the assembled code for an instruction like 

tra 7 Kad eee: 
ditch. eeeneeere fe the link named read whose contents, oe denned: will 
be an its pair potting i heve the DIM designer has placed the DIM's 


read function. 


The DIM must be written in Such a way as to return an error indica-_ 
tion when there is an attempt by the switch to transfer to an entry point 
that corresponds to an Geetiperced ie: aae eon. Here again, statue re- 
porting of attempts to utilize an Giauppoueed Function of a DIM is to 


‘be handled in convention-set way. The transfer vector element that would 


_%*  . The particular order of these entries is to be found in a listing 
of the so-called "transfer vector template'' which appears in the 
_MSPM section that overviews the I/O system. 


8- 39 
correspond to an unsupported function, e.g., ios $seek for the typewriter. 
DIM, is coded to send control to a small subroutine of fixed form* which 


fabricates the appropriate "entry-not-found" status word and returns to 


the 1/0 switch that called it. 


By way of summary it is well to repeat that the DIM writer can only 
supply as entry points a subset of those which are in the "vocabulary" of 
the I/O switch (currently those twenty or so entry points given in the 


ios_ section of the MPM.) | 


8.5.3 The DIM's Interface with the GIN 

With each Paad write function call, the DIM fabricates Data Control 
Word lists (DCW on and passes these to the GIM for further modification 
| atid use. There is a series of calls out Lined in the MSPM and in the MPM | 
under "GIOC calls" which the DIM must make in order to give Pie GIM an 
opportunity to "set itself up'"' to receive and employ these DCW lists and 
to perform its various communication tasks. To aace.ttach senge of these 
calls the reader aise Bequatne himself jit-tne GIOC hardware system 
peravence eace It is beyond the scope of this Guide to provide a suffi- 


ciently detailed explanation of the GIOC to make the DIM's calls to the 


GIM thoroughly meaningful. 


* More details can be found in the same MSPM discussion that was 
cited in the preceding footnote. © 
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A few general concepts can be wonveued neve however: First, it should 
be aensesca that the GIM's work areas and 1/0 buffers must be wired down 
because cies can only be referenced by the GIOC in an absolute addressing 
‘mode. The work areas are used for DCW lists that are compiled by the DIM 
and moved by the GIM from the virtual memory work areas designated by the 
DIM in its principal call on the GIM (at the entry point Ree crtserenanee. 
These transmitted lists are transformed by the GIM before being activated 
so that the address fields in the DCWs are in loaded-and- ready-to-use 
absolute form. The work areas are ae used for holding status words 
received feeh each channel and periodically copied over to corresponding 


work areas in the DIM's (virtual memory) data base. 


The I/O buffers are also necessarily wired down and are referenced 
by fe GIOC in absolute mode. The suepue buffer holds the actual data to 
be written out onto the channels. This data is copied by the GIM into its 
buffer bei a corresponding buffer previously established and filled by 
the DIM. Similarly the GIM's input buffers are necessarily wired down and 
filled directly by action of the GIOC during input channel activity. This 
data ie copied by the GIM from this buffer back onto the data aay 
designated by the DIM. The GIM knows how to move data into its output 
buffer or out of its input buffer to/from enous ocanciee DIM data arrays _ 
because the call(s) made by ee DIM to the GIM (at hes $list change) 


provide the required pointers. 


When the DIM is ready to ask the GIM to activate a DCW list, i.e., 


actually start the I/O (physically), the former makes a call requesting the 
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GIM to transmit a Channel Instruction Word for processing by the GIOC's 


so-called connect channel, 


Prior to transmitting a DCW list the DIM must issue two preliminary 

or "set-up" calls to the GIM. The first call (to hcs Sassign) ee the 
aeer-aeuess to the desired channel, The DIM requests such access by supply- 
ing a spo ie name and eccaiwtae in return a auiauelyseenereted device index 
(17 bits) to be used in all subsequent I/0 calls to the GIM for service 

on this channel. In the same call the DIM ea Aeris: dar cat channel name 
as an argument. This segaaeae would be previously obtained from the inter- 
process communication facility (IPC) as a result of a call to ipc $create_ 
event channel. It is by this event channel name that the process, when 
later blocked awaiting seep ieeicn aE a rere I/O operation, can be 
awakened by ‘the GIM. The GIM acts i's the interrupt handler for all 1/0 
jieerrupte: It consults a sriwbleced table which ie sega wherein are. 
recorded the channel name, device index, process _id, event channel name 
4-tuples. DIMs are ies scar vatmed to call ipc_$block when processing 
reads or writes that are synchronous or when the read-ahead or write-behind 


buffers are filled. 


Once the assign call has been successfully completed, the DIM, using 
the received device index - its key argument, can call the GIM again, 
This time the request is for the GIM to siiosarergurricrent wined down 
work space for the DCW list to be designated in subsequent calls that cause 
the DCW lists to hate nemieeed to that work Space and assembled into 


“loaded!! form. 
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The reader has hopefully been treated to the promised sketch of the 
DIM/GIM interface and is now on his own, ready for independent study, 


except for a few final remarks in the next section. 


8.6 Final Remarks 

A tour through the I/O system design would not be complete without 
observing that the 1/0 switch ~ DIM + GIM + GIOC chain is not absolutely 
mandatory as the only path allowed by Multics ee 1/0. A sophisticated 
aaeeaten designer will be the first to recognize that the 1/0 switch ~— DIM 
penton of this chain is strictly for user convenience. In principle, be-. 


cause the GIM may be called directly by the user, there is no reason why a 


designer could not bypass the I/O switch and DIM altogether for I/O to some 


Special purpose or dedicated devices and communication or channels. 

In essence the subsystem would eee with code that achieves the 
equivalent of many I/O switch and DIM functions but calls the GM directly 
using calls such as those suggested in Section 8.5.3. At all events the 
subsystem designer who diueses es travel this Ponte Should profit by a 
careful inspection of the 1/0 switch and DIM functions before launching 


into his own design that would allow a bypass of these modules, 
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